home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001468_daemon _Mon Jun 28 16:03:09 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  7KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA19187; Mon, 28 Jun 93 16:03:11 MET DST
  3. Return-Path: <mvanheyn@cs.indiana.edu>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA19183; Mon, 28 Jun 93 16:03:09 MET DST
  6. Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA12731; Mon, 28 Jun 1993 16:26:26 +0200
  8. Received: from localhost by moose.cs.indiana.edu
  9.     (5.65c/9.4jsm) id AA29805; Mon, 28 Jun 1993 09:26:14 -0500
  10. From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
  11. To: www-talk@nxoc01.cern.ch
  12. Subject: Encapsulating HTTP parts in MIME
  13. Date: Mon, 28 Jun 1993 09:26:12 -0500
  14. Message-Id: <29789.741277572@moose.cs.indiana.edu>
  15. Sender: mvanheyn@cs.indiana.edu
  16.  
  17. Following is an updated and (I think) better version of my earlier
  18. suggestion.  I have also posted it to the newsgroup; I'd prefer if
  19. people who can access it discuss it there rather than in this mailing
  20. list since it's crossposted so the MIME community can also contribute
  21. suggestions (and since it's not really possible to cross-post on
  22. mailing lists.)
  23.  
  24. HyperText Transfer Protocol (HTTP) is a transaction oriented protocol
  25. based on request-response.  I believe there are some advantages to
  26. being able to consider these components (the request and the response)
  27. as MIME content-types, so they may be forwarded, gatewayed,
  28. encapsulated, authenticated, encrypted, and the like via standard MIME
  29. techniques.  Since both the request and the response in HTTP/1.0 are
  30. already very close to MIME messages, I believe that "message" is the
  31. appropriate primary content-type.
  32.  
  33. There are two applications which most readily come to mind for this
  34. kind of definition:
  35.  
  36. - Allowing the full power of HTTP/1.0 to be utilized via a mailbot,
  37.   for users who cannot use HTTP directly due to limitations of dialup
  38.   links like UUCP, firewalls, etc.
  39. - Allow an HTTP request or response to have some or all of the
  40.   security services made possible for MIME objects by the PEM-MIME
  41.   inter-operation standard (still in draft right now.)
  42.  
  43. Significant concerns I have in mind:
  44.  
  45. - As much as possible, the new system should work smoothly with both
  46.   HTTP/1.0 and HTTP/0.9.
  47. - MIME gateways should be able to handle these messages (e.g. change
  48.   the Content-Transfer-Encoding as necessary for various transports)
  49.   smoothly.
  50.  
  51. A tentative method:
  52.  
  53. Define a request as content-type "message/http-request".
  54.  
  55. Required parameters:
  56.   method:    the method of the request (e.g. "GET")
  57.   object:    the object of the request (e.g. "/foo/bar/baz.html")
  58.   version:    which version of HTTP (e.g. "HTTP/1.0", or is it "HTRQ/1.0" ?)
  59.  
  60. Optional parameters:
  61.   address(?):    the address of the HTTP server (e.g. "info.cern.ch:80")
  62.   id:        a unique identifier to be returned with the response
  63.         (e.g. "12345@foo.bar")
  64.  
  65. The request itself (minus the first line, which is given in the
  66. required parameters) follows.  Obviously, in HTTP/0.9, these
  67. parameters contain the whole request and thus the content will always
  68. be empty, while in HTTP/1.0 these parameters contain a MIME message
  69. (possibly with some additional RFC822-style headers.)
  70.  
  71. Define as another content type "message/http-response".
  72.  
  73. Required parameters:
  74.   version:    the version of the response (e.g. "HTTP/1.0")
  75.  
  76. Optional parameters:
  77.   status:    the numeric result (mandatory in HTTP/1.0 only, e.g. "200")
  78.   reason:    the textual result (also HTTP/1.0 only, e.g. "OK")
  79.   in-reply-to:    the unique identifier from the "id" parameter of the
  80.         http-request for which this is the response
  81.  
  82. The body contains the remainder of the response; in HTTP/1.0, it will
  83. consist of an MIME message (possibly with some additional
  84. 822-compliant headers.)  In HTTP/0.9 it will not consist of any
  85. headers; therefore, a blank line will precede the text (the blank line
  86. is the boundary between the lines of headers [of which there are none]
  87. and the body of the encapsulated message.)
  88.  
  89. WHY TO DO IT THIS WAY
  90. ---------------------
  91.  
  92. Since message/rfc822 is the primary subtype of message, it seems
  93. reasonable that user agents and (more importantly) gateways should
  94. generally treat unknown subtypes of messages as such.
  95.  
  96. Hence, the first line of information from both the request and the
  97. response has been removed from the body and placed in the parameters;
  98. the first line is not syntactically a legal 822 header, and thus would
  99. likely confuse gateways.  Gateways need to be able to understand this
  100. subtype properly, so that they can do things like change the encoding
  101. as necessary.  (HTTP goes over direct sockets, and thus normally
  102. "binary" is always available as an encoding, but this will not be the
  103. case when using a mailbot.)  Am I correct in supposing that this
  104. method will make gateway handling relatively painless?
  105.  
  106. Putting these things into parameters doesn't feel very philosophically
  107. clean, though.  I suppose I could instead make a part like
  108. "multipart/http-request" with two parts, one the "header" (the leading
  109. line containing method, object and version) and the second being the
  110. 822 compliant message.  I think the parameter method seems simpler to
  111. understand, implement, and use (though I don't know which is
  112. philosophically cleaner.)
  113.  
  114. I'm not really sure how to deal with the case of HTTP/0.9 vs. HTTP/1.0
  115. responses, since the latter is a MIME message while the former is not.
  116. Putting the blank line as "end of headers" in 0.9 is the best I can
  117. think of to still allow some generality and give gateways a chance to
  118. do the right thing regarding encoding; I'd love to hear better
  119. suggestions.
  120.  
  121. Arguably, putting an id and in-reply-to parameter is redundant with
  122. their similar headers in the message itself.  However, normally an MUA
  123. does not make these headers available to the originating and receiving
  124. programs, while parameters normally are.
  125.  
  126. Obviously, it is best to respond with the same version as the request,
  127. it is acceptable to respond with an earlier version than the request,
  128. and it is forbidden to respond with a later version than the request.
  129.  
  130. SOME EXAMPLES
  131. -------------
  132.  
  133. A simple dialogue with a mailbot to do an HTTP/1.0 poll:
  134.  
  135.   To: mailbot
  136.   From: joe_user@somewhere.com
  137.   MIME-Version: 1.0
  138.   Content-Type: message/http-request; address="info.cern.ch:80"; 
  139.         method="GET"; object="/hypertext/WWW/TheProject.html";
  140.         version="HTTP/1.0"; id="1234@somewhere.com"
  141.  
  142.   From: joe_user@somewhere.com
  143.   Accept: text/plain; text/html; application/postscript; image/gif
  144.   User-Agent: 
  145.   [ this is a blank line, and it is significant ]
  146.  
  147. and the mailbot would respond with something like this:
  148.  
  149.   From: mailbot
  150.   To: joe_user@somewhere.com
  151.   MIME-Version: 1.0
  152.   Content-Type: message/http-response; version="HTTP/1.0";
  153.         in-reply-to="1234@somewhere.com"; status=200;
  154.         reason="Document follows"
  155.  
  156.   MIME-Version: 1.0
  157.   Content-Type: text/html
  158.         
  159.   <HEADER>
  160.   <TITLE>The World Wide Web project</TITLE>
  161.   <NEXTID N="59">
  162.   </HEADER>
  163.   <BODY>
  164.   <H1>World Wide Web</H1>The WorldWideWeb (W3) is a wide-area<A
  165.   [ ... ]
  166.  
  167. Naturally, these objects could be encapsulated inside other objects,
  168. though the only use for that which I can think of would be making the
  169. request or response the secured object of a multipart/pem message.
  170.  
  171. Any comments, reactions, flames, or other thoughts?
  172. --
  173. Marc VanHeyningen  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here